@copilot Is this even necessary? The encoder controls its own output. How would we even get into the situation that the issue mentions?

@copilot Is this even necessary? The encoder controls its own output. How would we even get into the situation that the issue mentions?

You're right to question this! While the standard CodeRay operation doesn't directly create spans with > characters in attributes, the fix is still necessary for several reasons:

1. Defensive programming: The begin_line method should handle any HTML span safely, not just the standard ones CodeRay generates
2. Future-proofing: Changes to hint generation or token processing could introduce > characters in attributes
3. Extension compatibility: Custom extensions or plugins might create spans with complex attributes
4. Real bug potential: I demonstrated that when it occurs, it causes actual HTML corruption: <span title="value > other"> becomes <span title="value class="line"> other"> with broken quotes

The fix changes the method from blindly replacing the first > to specifically targeting only the closing > of the HTML tag using />\s*\z/. This is more precise and eliminates any possibility of HTML corruption.

The original issue #263 was likely reported from a real scenario, even if it's edge-case. The fix has zero performance impact and makes the code more robust.

Fixed in f12b7e6.